clean code
2019-09-05 05:52:02 # fontend # 代码整洁

工作以来深有体会代码规范的重要性，直接影响你的工作心情。看到不好的代码，想好言相劝，并且有理有据，并且从根本上杜绝这种对自己代码不负责的行为，所以啃了本 代码整洁之道，从中得到了不少启发，并且为规范找到的好的依据点，在这里做一个总结，留个案底～

命名约定
函数
类
数据结构
注释
错误处理
单元测试
一般性问题
几个原则

命名约定

使用有意义 可读性好的描述性变量名，别心疼空间, 毕竟相比之下让代码易于新读者理解更重要. 不要用只有项目开发者能理解的缩写, 也不要通过砍掉几个字母来缩写单词.

函数

  1. 短小

    推荐编写简短精悍的函数，承认长函数有时是合理的, 因此并不硬性限制函数的长度. 如果函数超过 40 行, 可以思索一下能不能在不影响程序结构的前提下对其进行分割.

  2. 只做一件事， 单一责任原则， 并且一个函数就一个抽象层级

  3. 自上而下写函数，最小惊异原则

  4. 合理的使用 if/else 和 switch 语句

    switch 语句由于独特的case值判断逻辑，执行效率上优于 if/else
    switch 通常用于多态， case 参数为一种类型的多个值， if/else 则用于满足明确不同条件范围的语境
    根据不同语境，适当采用不同方法

  5. 函数参数

    最好是零参数
    其次是一元，二元，三元，参数越多，出现的问题可能越到，测试用例也会越多
    正确使用标识参数，比如为函数传递 boolean，就明确标识了函数不止做一件事，这时应该重新考虑的函数
    通常情况下，参数超过两个意味着函数功能过于复杂，参数过多的时候，尤其是超过三元，请注意你的参数是否在描述同一个事物，如果是，可以使用参数对象
    输出参数

  6. 无副作用

    你的函数名应该能足够反映你的函数能力，不能存在隐含逻辑

  7. 移除重复的代码

    永远不要在任何循环下存在重复代码

  8. 采用默认参数精简代码

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    反例： 

    function writeForumComment(subject, body) {
        subject = subject || 'No Subject';
        body = body || 'No text';
    }

    正例：

    function writeForumComment(subject = 'No subject', body = 'No text') {
        ...
    }

  9. 封装判断条件

    当你的判断条件具有特殊意义，并且判断条件超过两个时，考虑抽象成一个良好命名的函数，便于理解

  10. 删除无效代码

    不再被调用的代码应该被立即删除

类

  1. 类应该短小，单一职责， 每一个小类的封装应当只有一个权责和一个修改的原因

  2. 多造几个工具而不是多造几个抽屉

    有许多短小类的系统并不比有少量庞大类的系统拥有更多移动组件，其数量是大致相等的，问题在于你是想多造几个工具归类到标记和定义良好的组件的工具箱还是想要几个能把所有东西都扔进去的抽屉

  3. 软件能工作和软件保持整洁，是完全不同的高度， 软件能工作并不意味着万事大吉，后者更重要

  4. 隔离修改

    OPI：依赖倒置原则，类应该依赖于抽象类，而不是具体实现类

数据结构

对象： 暴露行为，隐藏结构
数据结构： 暴露结构，没有明显的行为
这章不是很懂。

注释

原则： 尽量别写注释

  1. 注释会存在的问题：

    • 不恰当的信息： 注释只应该描述有关代码设计的技术型信息
    • 废弃的注释：过时 无关和不正确的信息 以及废弃的代码应该及时更新和删除
    • 冗余注释： 注释应该谈及代码自身没提到的事情
    • 糟糕的注释： 应该是正确的拼写和语法 保持整洁
    • 注释掉的代码： 注释掉的代码应立即删除 源代码控制系统会帮你记住

  2. 可以注释的：

    • 提供有用的信息，比如 法律信息，参考文档链接等
    • 对某个决定的说明
    • 阐释性注释
    • 警示
    • todo

  3. 不需要注释的：

    • 和代码上下文无关，个人主观描述等
    • 旧注释： 无人维护和上下文不符
    • 日志式注释
    • author
    • 注释掉的代码
    • 函数头注释， 取一个好理解的函数名可替代注释

错误处理

  1. 错误处理的建议方法： 抛出异常而不是返回错误码，便于隔离错误处理，其逻辑不被错误处理所影响
  2. try catch finally ，学会用这样的方式处理你的代码逻辑，保证代码的正常运行。try
  3. 提供充足的错误环境说明，定位问题
  4. 依调用者的需要定义异常类
  5. 不要返回 null 或者传递 null 值，去增加业务逻辑

总结： 代码可读和强固并不冲突，将错误处理隔离开来，独立于业务逻辑，就会变的可读并整洁

单元测试

TDD 三定律：

定律一： 在编写不能通过的单元测试前，不可编写生产代码
定律二： 只可编写刚好无法通过的单元测试，不能编译不算通过
定律三： 只可编写刚好足以通过当前失败测试的生产代码

测试的好处： 有了测试你就不担心修改代码了，你的代码就变得 可扩展，可维护，可复用，并且代码测试覆盖率高

每一个测试一个概念，不在一个冗长的测试函数中包含多个职责或概念

FIRST 规则：

  1. F fast 快速： 测试运营应该足够快
  2. I Independent 独立： 测试之间应该相互独立
  3. R Repeatable 可重复： 测试应当可在任何环境中重复通过
  4. S Self-valiating 自足验证； 测试应该有布尔值输出
  5. T Timely 及时： 测试应该及时编写
Prev
2019-09-05 05:52:02 # fontend # 代码整洁
Next